For constructing, checking and terminating bi-directional end-to-end connections, based, e.g., on User Datagram Protocol (UDP), in telecommunication networks, by which, e.g., voice services such as Voice over Internet Protocol (VoIP) or the exchange of multimedia data is enabled, the so-called Session Initiation Protocol (SIP) is preferably used, as by this protocol additional services, e.g. for call checking, mobility and interoperability between various existing telephone systems can also easily be made available. The SIP messages used in this case are normally likewise transported by UDP packets. Signalling messages of the SIP protocol, such as, e.g. INVITE, include the IP address and information on the UDP port to which the reply, such as, e.g. 200OK, should be sent by the receiver of the first message. In the so-called SDP descriptor (SDP=Session Description Protocol) the SIP messages contain information on the User Agent Client (UAC), i.e. the caller, and the User Agent Server (UAS), i.e. the person called, including parameters such as, e.g. IP addresses and UDP ports for the media flow by means of the so-called Real-Time Transport Protocol (RTP).
For terminals located in a private IP area behind normally used devices such as a firewall with address transformation device, the private IP addresses are normally cited in the SDP descriptor and these terminals cannot therefore be addressed from outside the private IP area and are therefore not accessible. As the customarily used address transformation devices operate at the transition between the private and the public IP area only in layer 3 and/or layer 4 of the OSI model (OSI=Open System Interconnection), in this case only those IP addresses and ports cited in the headers of the UDP or IP protocol are transformed. The IP addresses and ports cited in the SIP or SDP protocols are contained in the so-called UDP payload and are not transformed by the address transformation devices, which results in the fact that between UAS and UAC private IP addresses and ports for the signalling and the RTP media flow are exchanged, with which no addressing and no accessibility of terminals in a private IP area is possible from outside this private IP area. Additionally, some UACs use two different ports for sending and receiving SIP messages, leading to the additional problem that even if a so-called pinhole in the firewall, in other words an opening for sending and receiving, is generated by an SIP message, such as, e.g. INVITE, the receipt of messages, such as, e.g. 200OK, is not possible at the port cited in the VIA entry of the SIP message, as in this receiving port, which in this case is not identical to the sending port anyway, no pinhole has been opened and therefore entry through the firewall is resisted. It can also occur with bi-directional RTP media flow that different UDP ports are used for sending and receiving RTP packets, so here too the problem mentioned arises.
Solutions to the above problem currently being discussed are, e.g. so-called helper protocols, such as Simple Traversal of UDP Through NAT (STUN) (NAT=Network Address Translator) or Traversal Using Relay NAT (TURN), with the aid of which a connection is produced between private and public IP addresses and ports and additionally pinholes are opened in the firewall, enabling a bi-directional RTP media flow. These solutions, though, require the installation of additional hardware, such as, e.g. servers, in the public IP area and additionally the terminals, such as, e.g. SIP telephones, must be equipped with special capabilities for evaluating and using the address transformations. Moreover, the solution based on the TURN protocol is hardly scalable, as the entire signalling and media traffic has to be conducted via a single server. Furthermore, the different kinds of address transformation, such as full cone NAT, restricted cone NAT, port restricted cone NAT, symmetric Nat, etc., are only partially supported by these approaches.
Another approach to solving the problems is to use firewalls with address transformation devices controlled by control protocols, such as, e.g. MIDCOM, MEGACO/H.248 or UpnP, based on SIP information from the application layer. However, this would require on the one hand upgrading or replacement of a multiplicity of firewalls with address transformation devices and on the other hand the installation of central or decentralised control units.
Finally, complete replacement of the firewalls with address transformation devices in the private areas with devices with the capability of SIP recognition, which are thereby capable of enabling the use of different UDP ports for sending and receiving, could also be undertaken by industry-wide agreement.
All the above-described approaches can solve the problems mentioned only partially or are very cost-intensive and complex.
The object of the invention is to create a remedy for the above-described situation.